home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000144_owner-urn-ietf _Thu Oct 31 14:53:42 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18748 for urn-ietf-out; Thu, 31 Oct 1996 14:53:42 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18730 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 14:53:39 -0500
  3. Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA27644  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:53:37 -0500
  5. Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA22604; Thu, 31 Oct 1996 11:52:05 -0800 (PST)
  6. Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA08639; Thu, 31 Oct 1996 11:52:21 -0800 (PST)
  7. Date: Thu, 31 Oct 1996 11:52:21 -0800 (PST)
  8. From: Terry Allen <tallen@fsc.fujitsu.com>
  9. Message-Id: <199610311952.LAA08639@ishtar.fsc.fujitsu.com>
  10. To: rdaniel@acl.lanl.gov, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com
  11. Subject: [URN] ig
  12. Sender: owner-urn-ietf@services.bunyip.com
  13. Precedence: bulk
  14. Reply-To: Terry Allen <tallen@fsc.fujitsu.com>
  15. Errors-To: owner-urn-ietf@bunyip.com
  16.  
  17. Ron writes:
  18. | >| 3.4  N2Rs (URN to Resources):
  19. | >| This resolution service returns multiple instances of a resource,
  20. | >| for example, GIF and JPEG versions of an image. The judgment about
  21. | >| the resources being "the same" resides with the naming authority that
  22. | >| issued the URN.
  23. | >
  24. | >All the instances that suit the Accept info the client has sent?
  25. | >Does that leave us with nothing between asking for one instance
  26. | >(N2R) and all (N2Rs), or is there some way to quality the request
  27. | >so that one receives no more than, say, 13 instances?  (Happy
  28. | >Halloween!)
  29. | 
  30. | I will add some words to the effect that the resolver MAY restrict
  31. | the resources returned to those that match the Accept: header.
  32.  
  33. That's good, but I can't find any way to use Accept: to limit
  34. the absolute number of resources that the client is willing
  35. to receive.  Have I missed it?  Is this perhaps an issue for HTTP and 
  36. not this group?
  37.  
  38. An image library might have scads of GIFs of the same object:
  39. the Parthenon in 1932, the P in 1964, the P at sunrise, the P
  40. under moonlight ... but it will be difficult to know in advance
  41. how to twiddle the Accept: information so as not to be inundated
  42. by Parthenons in response.  Or maybe that's okay and users should
  43. be warned that they may get more than the bargained for when they
  44. use N2Rs?
  45.  
  46.  
  47. Regards,